Modern SCADA in Containers: Advantages and Risks

javi
Panel industrial con pantallas de monitorización y luces indicadoras

SCADA (Supervisory Control and Data Acquisition) systems traditionally have been monolithic software on Windows Server with proprietary databases. In recent years, the trend is to containerize SCADA to leverage modern devops advantages: declarative deployment, scaling, observability. This article covers when it makes sense, what risks it introduces, and architectures that work.

Why Containerize SCADA

Concrete advantages:

  • Reproducible deployment: same setup in dev, staging, production.
  • Less traumatic updates: rolling update vs “power off system and migrate”.
  • Scaling: multiple HMI frontends with load balancing.
  • Observability: standard Kubernetes metrics, logs, traces.
  • Costs: less dedicated hardware.

Compatible Products

SCADA products supporting containerization:

The Fundamental Problem: OT ≠ IT

SCADA operates physical machinery. Failures have real consequences: plant shutdown, safety risk, equipment damage.

Consequence: you can’t apply DevOps patterns naively. A kubectl rollout restart isn’t acceptable if it affects a chemical reactor’s control.

Architectures That Work

Container Edge Layer + Real PLC

  • PLCs (Siemens, Rockwell, Omron) control hardware directly.
  • Containerized gateway aggregates data via OPC UA.
  • HMI in container, browser access.
  • Containerized historian for historical data.

PLCs maintain hard determinism; containers handle the flexible.

Dedicated OT Kubernetes Cluster

  • On-premise Kubernetes dedicated to OT workloads.
  • Strict segmentation vs IT.
  • GitOps for HMI/historian deploys.
  • Monitoring with Prometheus in same cluster.

Separated from corporate IT Kubernetes.

Hybrid: Legacy + Modern

Gradual transition:

  1. New HMIs in containers.
  2. Historians migrate to containers.
  3. PLC interfaces stay bare-metal initially.
  4. Aggregated dashboard over everything.

OT Security Risks

Honest about new risks:

Expanded Attack Surface

  • Exposed Docker socket = host control.
  • Accidentally accessible Kubernetes API = cluster access.
  • Unsigned images = supply chain attacks.
  • Badly segmented overlay network = easy lateral pivot.

Loss of Purdue Model

ISA/IEC 62443 defines levels (Purdue): L0 field, L1 control, L2 HMI, L3 operations, L4 enterprise. Containers can erase boundaries if you lack discipline.

Runtime Responsibility

Kubernetes updates, changes, evolves. A CRI change or default config shift can break OT invariants. IT ops rarely understands criticality.

Mitigations

Risk-reducing practices:

  • Real air-gap between OT cluster and rest.
  • Immutable infrastructure: no changes running; always rebuild.
  • Very strict policy enforcement (Kyverno, Gatekeeper).
  • Frequent backups of historian + config.
  • OT-specific monitoring (CrowdStrike, Claroty, Nozomi).
  • Emergency runbook: how to degrade to manual operation if incident.

Cybersecurity: NIS2 and Compliance

In EU, NIS2 mandates good practices in critical infrastructure. Container-based SCADA must meet:

  • Asset inventory.
  • Vulnerability management.
  • Incident response.
  • Supply-chain security.
  • Personnel training.

Recognised frameworks (IEC 62443) treat containers as part of total architecture — compliance isn’t automatic by containerising.

Real Cases

  • Shell: progressive modernisation with containers for HMI.
  • Siemens: own products support containerisation.
  • Electric grid operators: cautious pilots in renewable parks (less critical than nuclear plant).
  • Chemical plants: containerised historian and dashboards; fixed control.

No cases of fully containerised critical direct control — PLCs remain the base.

When NOT to Containerise

  • If no mature OT culture on containers.
  • If existing SCADA works well without modernisation driver.
  • In small systems (2-3 machines) where overhead isn’t justified.
  • If you can’t guarantee strict network isolation.

Adapted Observability

Stack we see working:

  • Prometheus for metrics.
  • Grafana for operational dashboards.
  • Loki/Elasticsearch for logs.
  • OT-specific monitoring overlay (Claroty, Nozomi).
  • Dual-path alerts (IT + OT channels).

Conclusion

Containerising SCADA is a real trend with clear operational advantages, but requires respecting OT context. It’s not devops-as-usual. Architectures leaving critical control in PLCs and modernising upper layers (HMI, historian, dashboards) are pragmatic. Air-gap, strict policy, and OT-specific monitoring are requirements, not options. For plants starting modernisation, beginning in renewables or new installations rather than migrating critical chemical plant is a sensible sequence. The journey is worth it for most — just must be done with discipline.

Follow us on jacar.es for more on Industry 4.0, SCADA, and OT security.

Entradas relacionadas